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(57) Abstract: A rate provisioning method and system of the present invention utilizes a rate table with pre-assigned cells that may 
^ be used by both IP bandwidth providers (partners) and IP bandwidth customers (retail IP service providers). The rate table enables 
its users to enter information about their IP Telephony preferences, including pricing criteria. This information can be used by an IP 
call-routing engine to provide the originating gateway operators with a prioritized list of terminating gateways whose pricing criteria 
match those set by the originating gateway operators. The rate table 
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of the present invention can be created with an ordinary spreadsheet computer program. After entering information into the pre- 
assigned cells of the rate table, a rate table can be saved in a file format that preserves the relative locations of the pre-assigned cells 
of the rate table. One such format is the CSV (comma separated values) format that can be used as a portable representation of the 
rate table. 
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5 RATE PRO VI SIONING METHOD AND SYSTEM 

FOR AN INTERNET TELEPHONY CLEARINGHOUSE SYSTEM 

PRIORITY AND RELATED APPLICATIONS 

The present application claims priority to provisional patent application 

10 entitled, "Automated Support of Internet Telephony Clearinghouse Services," filed on 
DecemFer"2271"999"and assigned U:S. Application" Sma~Number60/17T;375. The 
present application is also related to the following pending applications: U.S. 

Application Serial Number, , entitled, "System and Method for the 

Secure Enrollment of Devices with a Clearinghouse for Internet Telephony and 

15 Multimedia Communications," filed on December 22, 2000; U.S. Application Serial 

Number, , entitled, "Call Detail Record Method and System for 

Internet Telephony Clearinghouse System," filed on December 22, 2000; and U.S. 

Application Serial Number, , entitled, "User Interface for Internet 

Telephony Clearinghouse System," filed on December-22—2000; 

-20 

TECHNI CAL FIELD 

The present invention generally relates to a rate input mechanism for voice 
over IP (Internet Protocol) communications. More particularly, the present invention 
relations to a rate provisioning method and system that assists in the tracking of voice 
25 over IP communications from a source gateway to a destination gateway. 

BACKGROUND OF INVENTION 

As an alternative to traditional switched circuit networks, telecommunications 
service providers have discovered that voice telephone calls may be routed over IP 

30 networks. Due to the fact that the Internet is not presently subject to the same 
international regulations as are traditional telephone networks, routing telephone calls 
over the Internet tends to be less expensive. Additionally, an IP routed voice 
telephone call requires much less bandwidth, and thus less cost, than a voice 
telephone call placed over a traditional telephone network. Further, IP technology 

35 advances are entered into the marketplace at a much faster rate than traditional 
telecom technology. Thus, in order to be competitive, telecommunications service 
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5 providers have begun to use IP routing as a way to offer customers access to the latest 
technological improvements. 

Presently, however, there is no centralized system for routing voice telephone 
calls over an IP network. Each operator of a gateway is responsible for determining 
the routes for its own outgoing calls. Typically, gateway operators rely on traditional 
10 IP routing algorithms, which are designed to handle routing of computer generated 
data packets. Traditional IP routing algorithms attempt to strike a balance between 
the concerns of minimum delay and maximum reliability. Thus, using traditional IP 
routing algorithms, a voice telephone call will be routed to any destination gateway 
that happens to satisfy a set of predetermined criteria such as shortest path and 
15 acceptable data loss parameters. 

The routing of voice telephone calls, however, involves a significant concern 
that is not shared by traditional IP routing algorithms. This additional concern is the 
monetary cost of routing a voice call to a particular destination gateway. As in 
traditional switched circuit networks, Internet telephony gateways impose fees for the 
20 service of terminating a voice call. Traditional IP routing algorithms are not able to 
detect and compare the varying price schedules that may be imposed by various 
Internet telephony gateways. Thus, source gateways are not able to discriminate 
between destination gateways based on monetary costs. 

One way a gateway operator can establish the cost for IP telephony services is 
25 by negotiating directly with other gateway operators a fee for terminating each other's 
calls. These gateway operators could identify each other and establish a bilateral 
agreement or a multilateral agreement. This approach closely resembles that of the 
international circuit switch telephony network, where providers in each country have 
established bilateral and multilateral agreements with each other. A significant hurdle 
30 for this routing implementation, however, is the large number of business 
relationships that must be negotiated and maintained. For example, should 1,000 
local operators decide to interconnect via bilateral agreements, 999,000 separate 
agreements would be necessary. Interconnection through a centralized system, 
however, would require only 1,000 separate business agreements, each with a separate 
35 operator. 



f 
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5 Another disadvantage with a bilateral agreement model is that the gateway 

operators are not able to react quickly and intelligently to changing market forces 
because the bilateral agreements are generally long-term contracts. For example, 
when there is a sudden increase in demand for terminating calls to a particular area, 
the gateway operator in that area in unable to increase his terminating charges and 

10 — take advantage-of a demand. -Additionally, a bilateral-agreement -model or the 
multilateral agreement model are too cumbersome for the gateway operators to set 
call pricing based on selected call number ranges (any given subset of all possible 
telephone numbers). This is especially true if the total number of telephone numbers 
comprising a called-number range is too small. For example, it may be too 

15 cumbersome for the gateway operators to negotiate a specific call pricing plan for a 
specific customer with less than 1 00 numbers within their called-number range. 

Thus, there remains a need in the art for a method and system by which an 
originatin g gateway„operatoiimay.s^a_priceJ^ to pay to a terminating 

gateway operator for the service of terminating a IP telephony call. There's also a 

20 need for a method and system by which a terminating gateway operator may set a 
price that it is willing to accept in exchange for terminating an Internet Telephony 
call. There is a further need for a method and system configured for use by an IP 
routing engine for selecting routing options for a call based on matching the pricing 
criteria set by the originating and terminating gateway operators. 

25 There also remains a need in the art for a method and system by which a 

gateway operator may set or change call-pricing criteria on demand. There also 
remains a need in the art for a method and system by which a gateway operator may 
set or change call-pricing criteria associated with any subset of all possible telephone 
numbers. Additionally, there is a need in the art for a method and system which 

30 permits rapid implementation of changes to call-pricing criteria. Also, there is a need 
in the art for a method and system by which a gateway operator may set or change 
call-pricing criteria with minimal effort. There also is a need in the art for a method 
and system by which a gateway operator may set or change call pricing criteria by 
building upon previously-entered data. And lastly, there is a need in the art for a 
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5 method and system by whicl a gateway operator may set or change call pricing 
criteria that is simple for an onanary computer user. 

^SJUMMARYJ>E-I^^^ -_ - 

The present invention provides a method and system for defining pricing 
10 information to be used by a call-routing engine for the purpose of determining a 
preferred route for routing telephony ._ calls from an. originating gateway to a 
terminating gateway via an IP network. The Internet Telephony rate provisioning 
method and system of the present invention comprises a rate table with pre-assigned 
cells that may be used by both IP bandwidth providers (partners) and IP bandwidth 
15 customers (retail IP service providers). The rate table enables its users to enter 
information about their IP Telephony preferences, including pricing criteria. This 
information can be used by an IP call-routing engine to provide the originating 
gateway, operators -with a -prioritized list -of -terminating -gateways whose pricing 
^S$iH^mateh-to^ — Tfr e -q T} gj na ting 
20 customers enter information relating to call prices they are willing to pay for calls to 
-particulars may Q f ten 

specify pricing criteria, which defines the circumstances in which call price is to be 
applied. Similarly, the terminating customers enter information about the call prices 
they charge for terminating calls to particular numbers at particular times. 
25 Terminating customers may also specify pricing criteria of their own. Call pricing 
information generally describes call prices as well as pricing criteria. 

Call pricing information is but one example of preferences and preference 
criteria that may be used for the purpose of determining call-routing priorities. Other 
preferences include, but are not limited to, delay tolerance and expected reliability. 
30 Any preferences and preference criteria entered via the rate table may be stored in a 
database that is accessible by a call-routing engine. When a customer initiates a call, 
the originating gateway operator requests that the service point operator provide it 
with routing information necessary to terminate the call. Using call pricing 
information (i.e., call prices and pricing criteria) and other preferences and preference 
35 criteria derived from a rate table, the call-routing engine associated with the service 
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5 point operator determines ti e routing information corresponding to the most 
appropriate teraiinating gateways. A prioritized list of terminating gateways is then 
provided to the originating gateway. When provided with this prioritized routing 
, —information, the-originating gateway may eomplete-the-call by choosing to terminate 

the call via any one of the appropriate terminating gateways. 
, ... -_j : 0,==^^=^Usersxan.defme^ are 
- — ^^then-assembled-to^define-what-rates-are-preferred to what -numbers at=what -times, by 
both the originating and terminating customers. Basically, the users enter the pricing 
criteria into pre-assigned cells of the rate table. The pre-assigned cells in the rate 
table are locations within the rate table that relate to specific properties of the pricing 
15 criteria. For a user's convenience and to decrease improper placement of pricing 
criteria within the rate table, the user can be provided with a rate table template that is 
generated by the centralized or clearinghouse IP telephony system. 

A rate table can be created fo r_ each network device that is part of the 
centralized or clearinghouse IP telephony system. For example, a rate table can be 
20 created for each gateway that handles IP telephony traffic over the clearinghouse 
system. Each rate table can include a customer-identification number, anlnternet 
protocol address for the network device, the type of service supported (i.e. voice or 
fax), the type of rate plan (originating or terminating), a currency identifier, a rate 
plan name, a UTC (coordinated universal time)--based date on which the rate plan 
25 begins, and the call pricing information. However, the present invention is not limited 
to the aforementioned information. Also, a rate table may be configured such that 
certain cells are required cells while other cells within the rate table are optional. 

The rate table of the present invention can be created with an ordinary 
spreadsheet computer program. After entering information into the pre-assigned cells 
30 of the rate table, a rate table can be saved in a file format that preserves the relative 
locations of the pre-assigned cells of the rate table. One such format is the CSV 
(comma separated values) format that can be used as a portable representation of the 
rate table. Such a portable representation of the rate table allows the rate table to be 
transferred to the centralized or clearinghouse system relatively easy. That is, after 
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5 completing entry of data into the rate table, it can be saved in the CSV file format and 
then it can be transferred to the centralized system for validation and implementation. 
The centralized system can validate the transferred file containing the rate 

4able-mfermation-with~relative ease, since the CSV file format preserves the 

pre-assignment of cells within the rate table. In other words, upon receipt of the 
10 transferred file, the centralized system can reconstruct the rate table because of the 
preservation of relative.locations.of-the pre^assigned cells within the file format. The 
present invention is not limited to the CSV file format. Other file formats are not 
beyond the scope of the present invention. After validating and reconstructing the 
rate table contained within the transferred file, the centralized system can forward the 
15 rate information to one or more rate tracked network devices in the centralized system 
after a predefined period of time. 

With the present invention, call-pricing information for network devices can 
— - be-easily-generated- and modified with~ an application program that permits the 
~manipulaiion ofTaBrejfsucirarordjnary spreadsfieeT application pirogrims. In this 
20 way, once call-pricing information is entered for a network device, further updates to 
~~3he can^pficing IhTormatiorTcan be easily made when only a few entries are changed. 
That is, when the rate plans for certain network devices only require slight 
modifications, old rate tables containing previous rate information can be simply 
modified or changed. Such slightly modified rate tables can then be transferred to the 
25 centralized system for implementation of the new rate changes for the network 
devices that are part of the centralized Internet Telephony system. 

That the invention improves over prior rate implementation devices for 
centralized or clearinghouse systems and accomplishes the advantages and goals 
described above will become apparent from the following detailed description of the 
30 exemplary embodiments in the appended drawings and claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a functional block diagram illustrating one or more users that can 
be part of the centralized or clearinghouse system of the present invention. 
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5 Figure 2 is a schematic representation of an exemplary operating environment 

for the present invention. 

Figure 3 provides an overview of the steps involved in an Internet telephone 
~caiHh-the-exempl^ 

Figure 4 is an exemplary display screen for an e-mail message according to 

10 the present4nvention- - — ™~«-«™__ as ~™ 

— Figure-5-js-an -exemplaiy-dispiay-sereen-of a-user4nterfaee~for~uploading a file 

to a rate plan database of the present invention. 

Figure 6 is an exemplary rate table according to the present invention. 
Figure 7 is a logic flow diagram illustrating an exemplary embodiment of a 
15 method for creating and implementing an Internet Telephony rate plan for network 
devices of a centralized system. 

Figure 8 is a logic flow diagram illustrating an exemplary routine for 
transferring a file to the cent^^ forth in Figure 7: 

Figure 9 is a logic flow diagram illustrating an exemplary routine for receiving 
20 and validating data contained within a transferred file as set forth in Figure 7. 

Figure 10 is a logic flow diagram illustrating another-exemplary routine for 
transferring a file to the centralized system as set forth in Figure 7. 

Figure 1 1 illustrates another exemplary routine for receiving and validating 
data contained within a file as set forth in Figure 7. 

25 

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS 

The present invention is referred to herein as a rate provisioning method and 
system. The present invention provides a system and method for implementing 
preferences, such as pricing criteria, which are to be used by a routing engine for 

30 routing telephony calls from an originating gateway to a terminating gateway via an 
IP network. A telephone call occurring via an IP network is often referred to as a 
"voice over IP" transaction. When a "voice over IP" transaction specifically involves 
the Internet, the description "Internet Telephony" may also be used to describe the 
transaction. An exemplary embodiment of the present invention will be described 

35 herein with respect to Internet Telephony. However, the principles of the rate 
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5 provisioning method and system of the present invention apply to all IP routed 
transactions, including, but not limited to, 4 Voice over IP" calls, "fax over IP" calls, 
and "video over IP" calls. 



Exemplary Operatin g Environment 
'0 The following description of an ex emplary operating environment and 

exemplary em bodiments of the present inventio n will refer to the drawings, in which 

like numerals indicate like parts throughout the several figures. Referring to Figure 1, 
this figure shows an overview of a method of determining a preferred route for 
completing an Internet Telephony call using the rate provisioning method system 35 
5 of the present invention. The originating gateway operators 20 represent the retail IP 
telephony service providers that set the price charged for a call placed by a telephone 
user. The originating IP network backbone operators 25 represent wholesale IP 
^.bandwidth.providers.Jwho^have,agreements-with the originating gateway operators 20 
=te=pmvide the^bandwidth in-switching necessary to route the telephone call. 
► Similarly, the terminating gateway operators 15 represent the retail IP 

' -^Telephony- service provi ders that set the price for terminating^ a call placed by a 
telephone user. The terminating IP network backbone operators 30 represent 
wholesale IP bandwidth providers who have agreements with the terminating gateway 
operators 15 to provide the bandwidth and switching necessary to terminate a 
telephone call. Those skilled in the art will recognize that a gateway operator has the 
capacity to serve as a gateway for both originating and terminating telephone calls. In 
fact, originating gateway operators 20 and terminating gateway operators 15 typically 
differ only in the role played in a particular call. Similarly, backbone operators can 
handle both originating and terminating telephone calls. The originating backbone 
operators 25 and terminating backbone operators 30 typically differ only in the role 
played in a particular call. Henceforth, both an originating IP backbone operator 25 
and an originating gateway operator 20 may collectively, or in the alternative, be 
referred to as originating customers 26. Similarly, a terminating IP backbone 
operator 30 and a terminating gateway operator 15 will collectively, or in the 
alternative, be referred to as terminating customers 31. 
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5 The rate provisioning method and system of a present invention allows an 

originating customer 26 to define preferences, such as rates that it is going to pay for 
calls placed to particular called numbers at particular times. Similarly, the rate 
——provisioning -method ==and- systenv35- allows a terminating customer 31 to define 
preferences, such as rates it will charge for terminating calls to particular called 
_10 ~=numbers^ aU-particular times. Information relating to rates that an originating 
customer-26-is-going-to-pay-may-often-be-referred-to-as a^bid". . Information-relating 
to rates that a terminating customer 36 will charge for terminating calls may be 
referred to as an "ask". Henceforth, a bid placed and an ask placed collectively or in 
the alternative is referred to as call preferences. 
15 Besides call preferences, the preferences defined by a customer may also 

relate, for example, to call delay and reliability. An exemplary embodiment of the 
rate provisioning method and system 35 may allow customers to define circumstances 
Jnr which preference s are to be applied. For example, a customer may define 
preferences that relate to call preferences. A customer may also specify that the call 
20 preferences are to apply to calls made at certain times of the day, after a certain date, 
and/or to certain called telephone numbers:-Such criteria defming-when preferences 
are to be applied are referred to herein as preference criteria. In the case where the 
preference in question is a call preference, such preference criteria may be referred to 
as pricing criteria. Henceforth, the detailed description refers to pricing criteria in 
25 describing exemplary embodiments of the present invention. However, it should be 
understood that pricing criteria is just one example of preference criteria that may be 
used in the accordance with the present invention to match originating customers with 
terminating customers. 

As illustrated in Figure 1, the exemplary rate provisioning method and 
30 system 35 may comprise a component of a system referred to herein as a centralized 
system or clearinghouse 50. A clearinghouse 50 is configured to accept preferences 
and preference criteria, such as rate plans and schedules, from originating 
customers 26 and terminating customers 31, via the rate provisioning method and 
system 35. A clearinghouse 50 also implements functionality, which will be 
35 described below, for utilizing preference criteria in order to match an originating 
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5 customer's request to terminate a call with one or more terminating customers who 
are available to terminate the call and have pricing criteria and other preference 
criteria that match those defined by the originating customer 26. The matching 
described above may be performed in real time because both the originating 
customers 26 and terminating customers 31 may change their respective call prices 
10 and price criteria via the rate provisioning method and system 35 whenever they so 
desire. As shown, a clearinghouse 50 may further be configured to send to originating 
customers 26 a prioritized list of available terminating customers 31. 

Clearinghouse Network Architecture 
15 Referring to FIG. 2, this figure shows an network architecture that serves as an 

exemplary operating environment for the routing engine 1 10 of the present invention. 
As indicated, the Internet 102 serves as the heart of the exemplary network 

architecture — Relying on 4he-lnternct— 102-are five- different-systems that might 

^artieipatc4n-^m-internet Telephony'transaction.—These five systems include: a calling 
20 party 104, a source gateway (also referred to as an originating gateway) 108, a service 
- T3ointrll2 ;in^ referred to as a 

terminating gateway) 114 and a called party 118. As FIG 2 shows, a service point 
112 is coupled to a central database 120, which is also coupled to a billing and 
settlement system 124. While the service point 112 exists on the public Internet 102, 
25 the central database 120 and the billing and settlement system 124 remain in secured 
facilities. Private communication paths connect the remote equipment with the 
central database 120. 

The calling party 104 represents the user wishing to place a telephone call. 
Often, the calling party 104 will rely on a standard telephone handset to place the call. 
30 In fact, in many cases the calling party 104 may not be able to distinguish Internet 
telephony service from standard telephone service. The calling party 104 connects to 
a source gateway 108 through a public telephone network 105, such as a switched 
circuit network. In either case, the source gateway 108 serves as a bridge between 
ordinary telephones and the Internet 102 by converting telephone signals into data 
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5 packets (and vice versa) and transmitting the data packets over the Internet 102. A 
source gateway is operated by a source gateway operator 109. 

Similarly, the called party 118 is the user that receives a telephone call. A 
--^^illitf^^ telephone 
network 106, such as a switched circuit network. A destination gateway 114 is 

eonneeted4o4he-Internet-102~at-a4oGation-that-is-remote from.the source gateway 108. 

The-destination-gateway-H 44s-operated -by-a-destination-gateway-operator 115 and 

performs the same functions as the source gateway 108, i.e., bridging phone calls 
between the Internet 102 and a public telephone network 106, or an equivalent 
thereof. Destination gateways 114 differ from source gateways 108 only in the role 
15 played in a particular call. In particular, source gateways 108 act on behalf of the 
calling party 104, while destination gateways 114 act on behalf of the called party 
118. It is important to note that the same operator need not manage both the source 
"Zgateway 108 arid the destination gateway 114r ln "fact, the exemplary routing engine 
110, is tailored for environments in which different owners operate the two types of 
20 gateways. 

— "The ^ servicel>oint^pCTatbr~125lnay be a third party-that is-independent of the 
operators of the source gateway 108 or destination gateways 114. As indicated in 
FIG. 2, the service point operator 125 may maintain a private communications line 
with the service point 112, the billing and settlement system 124 and a related web- 

25 site 122. In the exemplary operating environment, all components maintained by the 
service point operator 125, i.e., the service point 112, the database 120, the billing and 
settlement system 124 and the web-site 122, are conveniently distributed between 
various geographic locations. Still, those skilled in art will appreciate that all 
components maintained by the service point operator 125 may be incorporated in a 

30 single system (service point 112) or any number of distributed systems. 

A service point 112 communicates with gateways over the Internet 102 and 
generally provides routing information to the source gateway 108. Given a 
destination phone number and other requirements (described in detail below), the 
service point 112, through the routing engine 110, identifies at least one appropriate 

35 destination gateway 1 1 4 to handle the telephone call. 
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5 The overall network frchitecture that serves as an operating environment for 

the exemplary routing engine 110 may be thought of as comprising three different 
networks, each carrying the telephone conversation. The first network is the calling 
— party_s4elephone network 105-that-connec-ts -the-calling-party-to-the-souree-gateway 
108. The second network is the Internet 102, which connects the source gateway 108 
10 and the destination gateways 114 to each other. The third network is the called 

party's telephone networ k 106 , which completes th e conne ction from the. destination 

gateway 114 to the called party 118. Although FIG. 2 (as well as this description in 
general) refers to the telephone connections as taking place through public telephone 
networks 105 and 106, Internet telephony service does not require such a connection. 
15 Some applications may use private networks, such as those provided by a private 
branch exchange; others may simply connect telephone handsets directly to the 
corresponding gateway. 

- -Additionally, a fourth network may be added -to the general network 

architecture— The^^ 126. A 

20 billing and settlement system 124 may be coupled to the service point 112 in order to 
vr^eceiverinfon^ of the Internet telephony 

transactions. The billing and settlement system 124 may use a banking and funds 
transfer network 126 to execute the financial transactions coordinated by the service 
point 112. 

25 

Internet Telephony Example 

FIG. 3 provides an overview of an Internet telephony call in the exemplary 
operating environment. At step 201, an Internet telephony call is initiated when the 
calling party 104 dials a telephone number, which is transmitted to the source gateway 
30 108 for processing. The goal of the source gateway 108 is to locate a destination 
. gateway 114a-c that is able to tenninate the phone call. The^source gateway 108 
relies on the service point 1 1 2 for routing assistance. 

At step 202, the source gateway 108 makes an authorization request to a 
service point 112. The authorization request indicates, among other things, the 
35 telephone number of the called party 118. At the service point 1 1 2, the routing engine 
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5 110 uses information in the authorization request, as well as preferences established 
for the source gateway's 108 CDst and quality requirements, to determine which of the 
destination gateways 1 1 4a-c ai e eligible to complete the call. 

ir . At step- 203 ^the - senvice^poinL.1 1 2_then. -sends-an^authorizationT response 

message to the source gateway 108, which includes information relating to the 

JO idsntit y_p f eligibl_e destinati on^gateways 114. In addition, the authorizatio n response 

_=messag£=JMntams=an_authoriza^ 

gateway 114. The authorization response ticket allows a destination gateway 114 to 
accept the call knowing that it has been authorized by the service point 112, and that 
the service point operator 125 will compensate the destination gateway operator 115 
15 for completing the call. 

Upon receipt of the authorization response message, the source gateway 108 
selects a destination gateway 114 from among the list provided by the service point 
112r -At step-204 r the-originating gateway-108 then- sends a setup-message to the 
selected destination gateway 114, as specified in International Telecommunications 
20 Union (ITU) H.323 and associated standards. Those skilled in the art will recognize 
that the_Q.931__standard may be used to define the-setup message.-_--To complete the 
authorization, the setup message must include the authorization ticket for the 
destination gateway 114. Those skilled in the art will also recognize that the user-to- 
user information element of the Q.931 setup message may be used to convey the 
25 authorization ticket. 

Communication between the service point 112, the source gateway 108 and 
the destination gateways 114 does not require the use of standard protocols for any 
aspect of the Internet telephony calls themselves, including call setup. If the source 
gateway 108 and destination gateways 114 use a signaling protocol other than Q.931 
30 (which is specified by H.323 and H.225.0), then that protocol need only be capable of 
including the authorization -ticket in -the-initial setup message. The exemplary 
authorization ticket is approximately 2000 octets in length. Destination gateways 
114a-c may accept or reject Internet telephony calls based on the presence and 
contents of this authorization ticket. 
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After the Internet telephony call is completed, both the source gateway 108 
and the destination gateway 114 transmit a call detail report to the service point 112, 
as represented in steps 205 and 206. Call detail reports identify the call and record its 
^uraffo^ m rmredin~ths^database ~!2 0 and - are accessed by the 

billing and settlement system 124 in order to reconcile financial obligations between 
the service point operator 125, source gateway operators 109 and destination gateway 
operators ,1-15.- — - - WOTOTS _^., : _. .„,. ..... ,. s 

It should be noted that source gateway 108 and destination gateways 114 are 
free to establish connections without consulting a service point 112. For example, a 
group of gateways may all be owned by a common entity and may wish to exchange 
calls among themselves independent of a service point 112. In such an environment, 
the gateways are free to rely on a service point 112 only when no gateway in the 
group can serve a given phone number economically. Thus, the exemplary operating 
environment provides gateways with extremely flexible routing choices. 

Xls67~those skilled in the art will appreciate tfiaTlhe exemplary operating 
environment may include multiple service points 112. Service points may be 
^istinguished bylhe specific services they provide, as well as_ by- their geographic 
location on the Internet 102. Geographic diversity optimizes performance by 
allowing a device to communicate with the closest service point 112. Proximity to a 
service point 112 minimizes delay in the communication exchange. Geographic 
diversity also increases the reliability of the operating environment. If one service 
point 112 becomes unavailable, devices using that service point 1 12 can automatically 
switch to a different service point (not shown) located elsewhere. 

Before a gateway is provided with access to a service point 112 the 
responsible gateway operator must enroll as a customer of the service point operator 
125. The customer enrollment process may take place through the web-site 122, via 
the Internet 102, using any well-known web browser. Gateway operators 109 & 115 
typically perform the enrollment from a desktop computer. Since the enrollment 
process typically requires disclosure of sensitive financial information (such as bank 
accounts or credit card numbers), the web connection between the gateway operators 
109 & 1 15 and the web-site 122 is secured by the secure sockets layer (SSL) protocol. 
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5 The web-site 122 uses SSL to authenticate itself to gateway operators 109 & 1 15 with 
digital certificates obtained from a trusted certificate authority. SSL also encrypts the 
information transferred between the gateway operators 109 & 115 and the web-site 

When the service point operator 125 accepts a gateway operator as a customer, 

.10 it_„prjoyides_the.xustoiner__with_a„customer number and password. The customer 

numbcr-is~Hamming-Goded-to^)roteet~against corruption.- Once assigned, customers 

are allowed to change their password. The service point operator 125 may enforce 
certain restrictions on passwords to maximize security. Such restrictions may include, 
for example, a prohibition against words appearing in dictionaries, a requirement to 
15 use both upper and lower case characters and a requirement that customers change 
their password periodically. 

After enrollment is complete, gateway operators 109 and 115 are given 
authorization to accessand modify their accountsr via thelntemet 1 02, through the 
web-site 12~2~~which~~may also host" the^te^rovisioning method andsystem 35. 
20 Enrolled customers may also be provided with access to timely and informative 
reports on their- usage-of-a service point 112. Such reports may include up-to-the- 
minute billing information, potential fraud alerts, sophisticated usage statistics and 
detailed traffic profiles. Enrolled users may access these reports directly through the 
web-site 122, using a web browser, or they can download the information for 
25 importing into their own database or spreadsheet. Users may also elect to be notified 
via electronic mail, fax, or other means when certain events occur. Events eligible for 
this service include suspicious or fraudulent activity, minimum or maximum traffic 
levels at particular devices, and apparent failure of a device. 

An enrolled customer may activate individual devices to use the services 
30 provided by a service point 112. In the present discussion, the exemplary devices are 
-Internet-telephony gateways 108 and 114. However, those skilled in the art will 
appreciate that the exemplary operating environment may be configured to supports a 
wide variety of devices. As with operator enrollment, device activation takes place 
across the Internet 102 using well-known web browsers. Typically, device activation 
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will take place at the device itself, while operator enrollment is performed from an 
operator's personal computer or workstation. 

The web-site 122 may be configured to support several different approaches 
— ibrlEtivating^ 1 22 

may be configured to support Windows, UNIX, and embedded operating 

^nvironments^JThose-skilled Jn-the_art_wilLrecognize„ that other .operating systems 

mayalso be supported. 

With respect to the Windows operating environment, exemplary web-site 122 
may be designed to support the operating environments of Windows 95, Windows 98 
and Windows NT version 4.0 and later (collectively referred to as "Win32 
platforms"). For these operating environments, reliance may be placed heavily on 
Microsoft's Internet Explorer (version 3.02 and later) to generate key pairs and to 
request and install certificates. The Certificate Server component of Microsoft's 
"Intem^ be used to grant certificate requests. 

As indicated in Figure 2, a clearinghouse 50 may comprise the components of 
a service point 112 (including a routing engine 110), a database 120, a website 122 
-hosting the rate provisioning- method and system 35 and a billing and settlement 
system 124. A service point operator 125 may be responsible for maintaining the 
clearinghouse 50. A service point operator 125 may be a third party that is 
independent of the originating gateway operator 20 or the terminating gateway 
operators 15. As illustrated in Figure 2, the service point operator 125 may maintain a 
private communications line with the service point 112, a billing and settlement 
system 124 and the website 122. In the exemplary operating environment, all 
components maintained by the service point operator 125 can be conveniently 
distributed between various geographic locations. Still, the skill of the art will 
appreciate that all components maintained by the service point operator 125 may be 
incorporated in a single system or any number of distributed systems. 

As mentioned above, a clearinghouse 50 may be configured to provide an 
originating gateway 108 with routing information relating to those terminating 
customers 31 who match the call prices and pricing criteria (and other preferences and 
preference criteria) set by the originating customers 26. A service point 112 
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5 communicates with gateways over the IP network 102 and generally provides routing 
information to an originating gateway 108. The service point 112, through the 
routing engine 110, identifies at least one appropriate terminating gateway 114 to 
handle a call. The service point 112 is coupled to the clearinghouse settlement 
platform that hosts the web-based user interface 122, the rate provisioning system 35, 
10 and the billing s ystem. The function of the rate pr ovision ing method and system 35 is 

ta_proYideL_^_mechamsm-_by_wW 

customers 31 may enter their respective call prices and pricing criteria to be used by 
the routing engine 110 in order to provide routing information to the originating 
gateways based on the best matches for their preferences and preference criteria. 
15 Also mentioned above, call prices are but one example for preferences that 

may be defined by an originating gateway operator 20. Other preferences may relate, 
for example, to delay times and expected reliability. The routing engine 110 may be 
— —configured to use-the-preferencesset-by the originating -gateway operator-20 as filters 
for eliminating "potential terminating gateways and determining the most appropriate 
20 terminating gateway to terminate a call. An originating gateway operator 20 may 
-specify -none- or any_combination of-preferences-as-its^filters. Also, an originating 
gateway operator 20 or a service point operator 125 may specify the maximum 
number of call routes that are to be returned by the routing engine 1 10 in response to a 
call authorization request. 
25 In an exemplary embodiment, a first preference referred to herein may be 

defined as "the maximum delay that an originating gateway operator 20 is willing to 
tolerate." The maximum delay is preferably the overall network delay, which is 
measured by the time taken for a signal to travel between the calling party 104 and the 
called party 118. The lower the network delay from when the calling party 104 
30 speaks to when the called party 118 hears the words, the higher the quality of the 
conversation. Those skilled in the art will appreciate that there are many other factors 
that determine delay or latency in a voice telephone call. Other examples of delay 
include: delay due to interlocking of digital conversation, buffering delays inside 
gateways, delays on public switch telephone networks (PSTN), etc. It is 
35 contemplated that such other sources of delay may be factored into the "maximum 
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5 delay preference." However, it is expected that network delay will be the most 
significant contributor to the overall quality of an Internet Telephony call. Thus, in 
the exemplary embodiment, other sources of delay can be ignored. 
- ^"^^^oiher prefer^ count 
that the originating gateway operator will tolerate." The IP network 102 may 
10 — ^oinprise^collett^^ traveling 
— from-an-eriginating gateway 108 to a terminating gateway 114 may traverse one or 
more autonomous systems. The fewer autonomous systems that a signal must 
traverse, the lower the network delay should be. While it is not necessarily true that a 
lower AS hop count will lead to lower delay, AS hop count does provide a good 
15 estimation of network delay. Furthermore, a lower AS hop count tends to suggest that 
there will be less signal loss (packet loss) when the voice signal reaches its 
destination. 

ATdeterm ination of AS hop count is instantaneous and~may be derived from 
information relating the dynamic topology of the IP network 102, which is dictated by 

20 congestion, etc., that is continuously gathered and stored in the database 120. To the 
contrary" network "delay- may -only be determined by an actual measurement, as 
described above, which involves significantly more time than an AS hop count 
calculation. Therefore, an originating gateway operator 20 may elect to use the AS 
hop count as hop count preference, rather than the "maximum delay" preference. 

25 An additional preference may be defined as "autonomous system (AS) 

matching," which dictates that, whenever possible, a route should be chosen such that 
both the originating gateway and the terminating gateway 114 are the same AS. A 
determination of AS matching is similar to a termination of AS hop count. A 
determination of AS matching dictates that given the choice of an AS hop count of 0 

30 and any other AS hop count, the route having the AS hop count of 0 will be chosen. 
-Similarly; "domain matching" and "platform matching" preferences may be defined, 
such that no terminating gateway 114 that operates in a specified domain or on a 
specified platform will be selected to terminate a call. 

Another preference can be "a maximum rate the originating gateway 

35 operator 20 is willing to pay for a call to a specific telephone number." All 
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5 terminating gateways 114 charging rates (the ask) that are greater than the bid are 
eliminated from the search for the optimal call route. A bid may be specified as a 
function of time of day, day of the week and/or destination. All preferences (bids and 
--~asks)-may be expressed^inr^ij^type of cuiTeney r and any fraction^thereof— -~ " 

An originating gateway operator 20 may set as many or as few preferences as 

. io it— would, like. It is-contemplated^that^ preferences other than the exemplary 

- ■— preferenees-dese^ribed-herein-may-also-be~implemented.™Eor~example, the originating 
gateway operator may also set preferences defining that all terminating gateways 114 
that are not intraoperable with the originating gateway 108, or do not offer the 
requested type of service, i.e., voice or fax, are to be eliminated from consideration. 
15 Other preferences may include, but are not limited to the following: "historical 
availability," which eliminates from consideration all terminating gateways 114 that 
have historical availability less than the required availability specified by the 
originating gateway^operator 20; "preferred" operator," which -eliminates from 
consideration all terminating gateways 114 thaf are noT~operated by a preferred 
20 operator specified by the originating gateway operator 20; "packet loss," which 
- -eliminates from -consideration-all terminating gateways 114 whose-historical packet 
loss is greater than the minimum specified by the originating gateway operator 20; 
"latency," which eliminates from consideration all terminating gateways 114 whose 
historical packet loss is greater than the maximum latency specified by the originating 
25 gateway operator 20; "quality of service (QoS) score" which eliminates from 
consideration all terminating gateways 114 whose QoS is less than the minimum 
specified by the originating gateway operator 20; "RSVP preference," which 
eliminates from consideration all terminating gateways 114 that cannot support, or are 
on networks that do not support, bandwidth reservation; and "best worst case," which 
30 eliminates from consideration all terminating gateways 114 whose best worst case 
scenario for packet loss and latency exceeds the minimum best worst case scenario 
specified by the originating gateway operator 20. The best worst case is estimated by 
summing packet loss or latency between the originating gateway 20 and the reference 
point maintained by the service point operator 125 plus the latency and packet loss 
35 between the terminating gateway and a service point operator 125. For example, the 
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5 worst case for packet latency between the originating gateway 108 and the 
terminating gateway 114 and assumed to be equal to the packet latency between the 
originating gateway 108 and the service point operator 125 plus the terminating 
-gateway-and-the service point operator 125: '" ~" fv^— rr - r--__r- - 

_1 0 =^ateJgroyjsip,mng.Mefa — — ~— _ _.. 

- ^^^rr^^R^ferang^now^to— Eigure-4^this 

screen 400 for generating an e-mail message 410 that can be transmitted from an 
originating customer 26 or a terminating customer 31 The e-mail message 41 0 can be 
generated by any application program such as Microsoft Outlook or other types of 

15 application programs. The e-mail message 410 is but one method of transferring a 
rate plan table to the centralized or clearinghouse system 50. In this exemplary 
embodiment, the e-mail message 410 has a "To" field in which the e-mail 
message 41 0 is ad dressed. The e-mail message 410 further includes a "subject" 
field 430 that has a predefined format. The predefined format includes the word 

20 "provision" followed by the variables A, B, C, and D. The variable "A" can represent 
. -the customer or subscriber identification number while the variable . "B" can represent 
a gateway identification number. The variable "C" can represent the service type 
(such as voice or fax). The variable t4 D" can represent the traffic type (such as 
originating or terminating). The file attachment 440 should contain the rate trend 

25 table that has been saved as a CSV (comma separated values) file format that saves 
only the text and values as they are displayed in cells of the rate plan table. With this 
file format, the relative locations of pre-assigned cells within the rate plan table are 
preserved. For example, with the CSV file format, all rows and all characters in each 
cell of a table are saved. Columns with data are separated by columns, and each row 

30 of data ends in a carriage return. If a cell contains a comma, the cell contents are 
enclosed in double quotation marks. The present invention is not limited to the CSV 
file format. Any file format can be utilized as long as the file format preserves the 
relative locations of the pre-assigned cells within the rate table. 

Figure 5 illustrates another exemplary display screen 500 that includes a user 

35 interface 510, which can be hosted by website 122 (See Fig. 2). The user interface 
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510 may have multiple framer. where one frame displays a logo 520 of a user. Other 
frames can display a navigational tool 530 for navigating through the data supported 
by website 122. Another frame can include other tools or links such as the "upload 
-new-rate : plan"4ink-540.— Upon activating link 540, the^user can-designate a location 
of the file containing the rate plan table that provides for the new or updated rate plan 
..information.. Similar_.to_the_embodiment_discussed„with respect to Figure 4, the file 
^ontainiiig4he-rate-plan-table-for4he-embodimentJllustrated-in Figure. 5-shouldalso be 
saved in a file format that preserves the relative locations of the pre assigned cells 
within the rate table. Preferably, in the exemplary embodiment, such a file format is 
the CSV file format discussed above. 

Figure 6 illustrates an exemplary rate plan table 600 according to the present 
invention. This rate plan table 600 can be created by an application program 
supporting tables such as an ordinary spreadsheet program like Microsoft Excel. 
Each cell 610 of the table is defined according to a row number and a column number. 
For example, cell 610A is defined by column B, row 1. Cell 610A can contain a 
customer identification number. Cell 61 0B can denote the gateway identification 
number from a device-information-page of "the -user interface-hosted~by~website 122. 
Further details of the remaining cells 610C through 610Q will be discussed and 
explained in further detail in Table 3 listed below. The present invention is not 
limited to the cell assignment illustrated in Figure 0. Different cell assignments, as 
well as increased or decreased number of cells with respect to those shown in 
Table 600 can be provided. In other words, the present invention is not limited to the 
number and type of cell assignments illustrated in Figure 6. 

Referring now to cell 610G, the cells that fall within the column defined by 
cell 61 0G refer to predefined geographical regions that can be used in setting up a 
single rate for a grouping of countries. For example, in the rate plan table, you can 
create one rate row for a region denoted as "AS" represents the geographic region of 
Africa. In the geographic region of Africa, a user may establish rate rows within the 
rate table for specific countries within the predefined country region, such as Egypt 
and Libya. In this example, all countries in the Africa region would inherit the rate 
for the "AS" region, except for the countries of Egypt and Libya (since these 



WO 01/47235 



22 



PCT/USOO/35069 



5 countries would have their own separate rate rows within the rate plan table). Such a 
system prevents the user having to create multiple rows for multiple countries in the 
same zone with the same rate. 

~ r: ^ -^LsMoth^ 

Table I. Table I demonstrates how separate rate rows can be created for individual 

10 ^ountiies^ito For example, 

- -according-to-Table-I^allcalls4o .J4048Sl-4wllJiav«-a.rate-of-Q.0555,Junils.-.4See the 

third row of Table I). All calls to 1404 (and not to 404851) will have a rate of 0.055 
units. (See row 2 of Table I). All calls to 1 (and not 404) will have a rate of 0.05 
units. (See the first row of Table I). All calls to country code 33 (France) will have a 
15 rate of 0.08 units. (See the fourth row of Table I). All calls to countries in the Europe 
country zone (except France) will have a rate of 0.09 units. (See the fourth row of 
Table I). All calls to all other destinations will have a rate of 0.15 units. (See the 
~sixth Trow of Table I). " ~ " 

20 Table I - Zone Rate Assignment System - Illustration 1 



Zone 


cc - 


City fcode/NPA- 
NXX 


Rate 




1 




.05 




1 


404 


.055 




1 


404851 


.0555 




33 




.08 


HU 






.oy 


OT 






.15 



Another example of assigning rates to calling zones and specific locations 
within a calling zone is illustrated in Table II. According to Table II, the first row, all 

25 calls to countries in Central/South America will have a rate of 0.08 units. Meanwhile, 
according to the second row of this table, all countries in Asia except to city code 1 in 
Turkey (country code 90 -- see the fourth row of Table II) and to China (country code 
86 - see the third row of Table II) will have a rate of 0.09 units. All calls to China 
(which has a country code of 86) will have the rate of 0.10 units. All calls to city 

30 code 1 in Turkey (which has a country code of 90) will have a rate of 0.1 1 units, as set 
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5 forth in the fourth row of Table II. All calls to all other destinations will have a rate 
of 0.12 units, as set forth in the fifth row of Table 2. 

— Table : n—Zo!^Rate Assignment System —Illustration 2 ~- 



Zx»ne 


cc 


City Code/NFA- 


Kate 






NXX 


SA 






-108 


AS 






109 




86 




no 




90 


1 


111 


Ol 






112 



10 

A calling zone may comprise one of the following regions: "AF", which 
denotes Africa; "EU", which denotes Europe; "AP'\ which denotes Australia/South 
Pacific; "AS", which denotes Asia; "CA'\ which denotes Central and South America; 
„and "OT\ which denotes the rest of the word. The country codes for the countries 
15 contained within the aforementioned zones are listed in Table VI. The country codes 
listed in Table VI may not include the latest and most accurate E.164 country codes. 
According to the International Telecommunications Standard ITU E.164, an 
international telephone number consists of a one to three-digit country code followed 
by no more than twelve additional digits. The first digit of the country code may be a 

20 digit from one to nine, and this is called a "zone." Therefore, all possible telephone 
numbers may be divided into called number ranges roughly by zone, or finally by 
country code, and with increasing specificity as the length of the number prefix is 
extended. By way of illustration, a called number prefix ("+]"), dialed from 
anywhere in the world, defines a called number range that includes telephone 

25 numbers in North and Central America (the plus sign is an international convention 
that represents whatever the user must do in preface to making an international call. 
In the United States, that usually means dialing the digits "011," but the exact 
procedure varies from country to country). Similarly, the called number prefix of 
"+1404" defines a called number range that includes numbers in Atlanta, Georgia. 

30 The exemplary rate plan table cf the present invention is configured to allow a 
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5 number prefix having a maxiiaum of fifteen digits due to the fact that an international 
telephone number includes up to fifteen digits by convention. However, should there 
be a reason to extend a called number prefix past the current number of fifteen digits, 
the rate plan tabl¥oTffie prwent inVehtion may be configured-todo so. " ~ 

Any countries not included in the zones set forth in Table VI are not 
- 10— considered-part-of-a-predefmed-region^and4he-number^string will have to be defined 

^in"the-counti7-code-and~city-code/NPA-NX-X~eolumns-of the -rate plan table. 

However, the present invention is not limited to the E.164 country code standard. 
Any grouping of countries or cities or both can be adopted by the present invention. 

Referring now to Table III, as mentioned above, this table describes the cell 
15 assignments for the rate plan Table 600, as illustrated in Figure 6. As noted above, 
Table III and Table 600 of Figure 6 are illustrative exemplary embodiments of the 
present invention. In other words, the present invention is not limited to these cell 
assignments as can be appreciated to those of ordinary skill in the art. 



20 Table III - Cell Assignments 



Cell(s) 


Description/Action 


1A 


iinter the label "Customer ID" 


IB 


Enter the subscriber ID trom the General inlormation page ol the User 
Interface. 


2A 


Enter the label "Device Name". 


2B 


Enter the gateway ID trom the Device inlormation page ot the User Interlace. 


3A 


Enter the label "Service Type". 


3B 


iinter "V" tor voice or "K tor tax. 


4A 


Enter the label "Assignment J ype . 


4B 


Enter u O" ibr originating rate plan assignment or " 1 tor terminating rate plan 
assignment. 


5A 


fcnter the label "Currency". 


5B 


Enter w l" (lor $US). 


6A 


iinter the label "KF Name". 


6B 


Enter an 8-character name tor this rate plan. 


8A 


Enter the label "BEGIN" 


9A:9C 


This is the Called Number String composed of values in columns A through C. 

Zone (column A value) may be: 

# <blank> 

# AF = Africa Region (see list of countries in Table VI) 
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# EU = Europe R( gion (see list ot countries in Table VI) 

# AP = Australia/South Pacific Region (see list of countries in Table VI) 

# AS = Asia Region (see list of countries in Table VI) 

# SA = Central and South America Region (see list of countries in Table VI) 

# . OT =-Rest of -World:(all files:must:include.at Jeastione_row with this value 
which is a default region) 

If one of the above values appears in Column A, there cannot be values in 
Columns B and C and vice versa. You may define rates by: 

# Region"(input Region code in column A; no values in columns B and C) 

# Country Code (input country code value in column B; no values in 
columns A and C) 

# Combination of Country Code and City Code (input country code value in 
column B and city code or NPA/NXX in column C; no value in column A) 

Columns B and C represent the Country Code and City Code respectively. 
The sum of digits in columns B and C may not exceed 7. 




enter raie in juo per minute, vajue may oe up 10 *+ uccimai places. 




Enter u 60". 




Enter "second". 




Enter the date when this rate becomes elective. Usually this will be the 
current dater~But it is also possible to schedule future changes. That is, you 
may create several rows with the same number string but with different begin 




dates and different rates as long as one of the begin dates is less than or equal 
to the date/time the file is submitted to the centralized system 50. 


9H 


Leave blank, (tuture use) 


9J 


Leave blank, (tuture use) 


9J 


It rates are for terminating gateway, enter "Y" it termination is allowed to this 
gateway for this row's Called Number String. Enter "N" if termination is not 
allowed. 

If rates are for originating gateway, enter "Y" if origination is allowed from 
this gateway for this row's Called Number String. Enter "N" if origination is 
not allowed. 



5 

Referring now to Table IV, this table explains which particular cells within the 
rate plan table are required to have values. The table also provides an additional brief 
description of each cell's content. It is noted that some descriptions refer to a 
"phase". This "phase" is identifying how the present invention can be implemented in 
10 stages. During an initial phase, such as Phase I, the functionality or capability of the 
clearinghouse system 50 may be somewhat limited. After subsequent phases, such as 
Phase II, functionality of the clearinghouse system 50 will be enhanced to include 
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5 additional capabilities or options. Some descriptions of Table IV also refer to 
"UTC-based dates" UTC denotes coordinated universal time, which is the standard 
time common to every place in the world. In other words, UTC normally reflects the 
— mean-solar time-along-the-prime-meridian-(0 degrees longitude) that runs through the 
Greenwich Observatory located outside of London, UK, where the current system 
.10 originated. Coordinated universal time is ex pressed us ing a 24-h our clock and uses 

— the-Gregoriancalendar It is-used-in-airplane.and„ship_navigation,„whereJt is also 

sometimes known as "Zulu time", Zulu being the military word for the letter "Z" and 
for the longitude 0. The full definition of coordinated universal time can be found in 
ITU-T Recommendation X.680 (7/94). 

15 

Table IV - Required and Optional Ceils for Rate Plan Table 600 of Fig. 6 



Cell or 
Row or 
Column 


Ken ui red 


Description 


til 


Y 


User enters Customer ID 


B2 


Y 


User enters IP Address (IP UN 1 ) 


J» 


Y 


In Phase 1, only "V" (voice) or "F" (tax) or 
supported. 


B4 


Y 


User enters "'J'" tor terminating rate plan or "O" 
for originating rate plan 


B5 


Y 


Currency ID 


Bo 


Y 


User enters rate plan name (up to 8 alpha- 
numeric). 


Column 
A(A9) 


N i J Column 
B has a 
value, Y if 
Column B 
does not 
have a value 


Zone may be: 
AF = Africa 
EU = Europe 

AP = Australia/South Pacific 
AS = Asia 

SA = Central and South America 

OT = Rest of World (all files must include at 

least one row with this value) 

If one of the above values appears in Column A, 
there cannot be values in Columns B and C and 
vice versa. 


Column 
B(B9) 


N il Column 
A has a 
value, Y if 
Column A 


Note that "1 is the country code tor all North 
American locations. All valid country codes 
(outside North America) are listed in Section 6 of 
this document. 
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does not 
have a value 




Column 
C(C9) 


M 


1 his is the city code or JNFA-NXX. This value 
may be up to 6 digits. 


Column 
D(D9) 


See .Section ~. 
5, item 5 


U ser enters rate^per minute„(up to 4 decimal - 

places). 


Column 
E(E9) 


See Section 
5, item 5 


In phase 1, only "60" is supported. 


Column 
F(F9) 


See Section 
5, item 5- 


in phase I, only "second" is supported. 


Column 
G(G9) 


Y 


User enters the U I C-based date on which this 
rate begins; format mm/dd/yy 


Column 
H(H9) 


N 


(Applicable to Origination Rate Flans only; see 
cell B4) 

In Phase I, this field will be left blank. 
In Phase II, user enters Maximum Delay in 
milliseconds. This is an optional field. User 
may leave blank or enter any of the following 
- values to be determined. . _ _ 


— Column — 


— See Section 


(Apphcable-to Origination-Kate Flans only; see 


109).- 

. i.. . 


5, jtem 5 

■-- r_ 


; _cel!.B4)_ 

In PhaseJ, "LC!lis supported 

In "Phase II, user may enter one of the following 

Routing Priorities: 

"LC" (Least Cost) 

"LD" (Least Delay) 

"SA" (Same Autonomous System) 


Column 
J(J9) 


Y 


User enters "Y" to allow ongination trom or 
termination to this device; otherwise, "N" 



5 



Referring now to Table V, this table provides an explanation of various cells 
contained within the rows of Table 600 of Figure 6. The information contained 
within Table V assumes that the rate plan data contain within Table 600 arrived at the 
service point 125 on July 16, 1999 at 3:00 a.m. UTC. 

10 

Table V - Explanation of Rate Plan Data in Table 600 of Fig. 6 



Row 


Explanation 


9 


• This device will be a candidate to terminate calls to "1 " (but not those 
matching 1770452, 1770 or 1404) from 7/16/99 03:00:00 UTC through 
7/3 1/99 23:59:59 UTC @ .04/min. 
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10 


• This device will be a candidate to terminate calls to "1" (but not those 
matcnmg l / /U43Z, i / /u or i**uhj irom 0/ i/yy uu.ou.ou or later (gj 
.045/min. 


A A 
11 


# 1 lus device will be a candidate to terminate calls to 1404 Irom 7/1 o/yy 
03 :00:QO T lTrrnr later @-042/min: 




• This device will be a candidate to terminate calls to 4i 1770" (excluding 
1770452) from 7/16/99 03:00:00 UTC or later @ .043/min. 


-13 


_This.device-will-be-a.candidate.to-terminate calls to "1 77045" from 

"7/1 /T /OA AO .A A. Art T TTT/^' A — 1 n i A _ Arc "_ 

//l o/yy 03:00:00 U J C or later @ .055/min. 


14 


• This device will be a candidate to terminate all calls to Europe (CC's = 3 

/l\ .f.-- . ^7 / 1 /T /rtA A"5.AA.AA 7TTP 1-,*—— /Ov A "7 "7 

or 4) irom 7/1 6/99 03:00:00 U I C or later (g} .0 / //min. 


15 


# This device will be a candidate to terminate all calls to Africa (CC's = 2) 
except Morocco (CC 212) from 7/1 6/99 03:00:00 UTC or later @ 
.oyiz/min. 


16 


9 This device will be a candidate to terminate all calls to Morocco (CC = 
212) irom 7/16/99 03:00:00 U1C or later (g2 .343/min. 


17 


# This device will NOT be a candidate to terminate calls to "54 1 1 " from 
7/16/99 03:00:00 UTC through 8/14/99 23:59:59 UTC since "Allow" = 
4 TNT. 


18 


• This device will be a candidate to terminate calls to 54 1 1 irom 8/1 5/99 
00:00:00 UTC or later @ .065/min. 


19 


# In the context of this rate plan, "OT" includes all calls to "5" (except 
"541 1"), "6", "7\ "8" and "9". This device will be a candidate to 
terminate calls matching those number prefixes from 7/1 6/99 03:00:00 
UTC or later @ .070/min. 



5 

Referring now to Table VI, as mentioned above, this table lists the individual 
countries that form each of the five calling zones that include "AF" for Africa, "EU" 
for Europe, "AP" for Australia/South Pacific, "AS" for Asia, and "SA" for Central 
and South America. Also listed adjacent to each country contained within a zone is 

10 each country's country code according to the ITU E.164 standard. It is noted that 
these lists may not include the latest and most accurate E.164 country codes. The 
most current listing of the country codes can usually be found at the following 
website: www.itu.ch. According to the present invention, any countries not included 
in Table VI are not considered to be part of a predefined region, and therefore, the 

15 number string for a particular country not considered part of a predefined region may 
have to be defined in the country code and city code/NT A-NXX columns of the rate 
plan table. It is noted that the columns of Table VI are in a "newspaper" format. Data 
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in one column on a page con inues to an adjacent column (in a left to right, top to 
bottom fashion) when the da:a of Table VI is displayed on more than one page. 
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laoie VJ - Predefined Regions and Countries in each Kcgion 



Africa (AF) 


20 




Egypt 


212 




Morocco 


213 




Algeria 


216 




Tunisia " 


218 




Libya 


220 




Gambia 


221 




Senegal 


222 


mm 


Mauritania 


■2-2-3- 


— mm- 


-Mali— Republic 


224 


~~ 


Guinea (PRP) 


225 


*~ 


Ivory Coast 


226 




Burkina Faso 


227 


— 


Niger 


228 




Togo 


229 




Benin 


230 




Mauritius 


231 




Liberia 


232 




Sierra Leone 


233 




Ghana 


234 




Nigeria 


235- 




Chad , ... _ 


236 




Central 


African Republi c 


237 




Cameroon 


238 




Cape Verde 



Islands 

239 - Sao Tome and 
Principe 

240 - Equatorial 
Guinea 

241 - Gabon 

242 - Congo 

243 - Zaire 

244 - Angola 

245 - Guinea-Bissau 

246 - Diego Garcia 

247 - Ascension 
Island 

248 - Seychelles 
Islands 

249 - Sudan 

250 - Rwanda 

251 - Ethiopia 

252 - Somalia 

253 - Djibouti 

254 - Kenya 

255 - Tanzania 

256 - Uganda 

257 - Burundi 



258 - Mozambique 

260 - Zambia 

261 - Madagascar 

262 - Reunion 
——Island "... 

263 - Zimbabwe 

264 - Namibia 

265 - Malawi 

2 6 6^ Les o tho 

267 - Botswana 

268 - Swaziland 

269 - 

C omo r o s /Mayo t te 
Island 

27 - South Africa 

290 - St. Helena 

291 - Eritrea 

298 - Faeroe 
Islands 

299 - Greenland 



Europe (EUr : 


30 - 


Greece 


31 - 


Netherlands 


32 - 


Belgium 


33 - - 


. France 


34 - 


Spain 


350 - 


Gibraltar 


351 - 


Portugal 


352 - 


Luxembourg 


353 - 


Ireland 


354 - 


Iceland 


355 - 


Albania 


356 - 


Malta 


357 - 


Cyprus 


358 - 


Finland 


359 - 


Bulgaria 


36 - 


Hungary 


370 - 


Lithuania 


371 - 


Latvia 


372 - 


Estonia 


373 - 


Moldova 


374 - 


Armenia 


375 - 


Belarus 


376 - 




Andorra/Vatican 


City 




377 - 


Monaco 


378 - 


San Marino 



380 - Ukraine 

381 - 

Yugos lavia / Serbia 

385 - Croatia 

386 - Slovenia 

387 - Bosnia & 
Herzogovina 
389 - Macedonia 

39 - Italy 

40 - Romania 

41 - 

Switzerland/Liechte 
nstein 

420 - Czech 
Republic 

421 - Slovak 
Republic 

43 - Austria 

44 - United 
Kingdom 

45 - Denmark 
4 6 - Sweden 

47 - Norway 

48 - Poland 

49 - Germany 

Central /South 

America (SA) 

500 - Falkland 
Islands 

501 - Belize 

502 - Guatemala 

503 - El Salvador 

504 - Honduras 

505 - Nicaragua 

506 - Costa Rica 

507 - Panama 

508 - St. Pierre & 
Mi que Ion 

509 - Haiti 

51 - Peru 

52 - Mexico 

53 - Cuba 

54 - Argentina 

55 - Brazil 

56 - 

Chile /Easter_Island 

57 - Colombia 

58 - Venezuela 
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590 - Guadeloupe 

591 - Bolivia 

592 - Guyana 

593 - Ecuador 

594 - French Guiana 

595 - Paraguay 

596 - 

Martinique/French_A 
ntilles 

597 - Suriname 

598 - Uruguay 

599 - Netherlands 
Antilles 



Australia/South 
Pacific (AP) 

60 - Malaysia 

61 - 

Australia/Cocos- 
Keeling Islands 

62 - Indonesia 

63 - Philippines 

64 - Mew 
Zealand/ Cha tham 
Island 

65 - Singapore 

66 - Thailand 

670 - Mariana 
Islands 

671 - Guam 

672 - Christinas & 
Norfolk 

I s 1 ands /An tar c ti ca 

673 - Brunei 

674 - Nauru 

675 - Papua New 
Guinea 

676 - Tonga Islands 

677 - Solomon 
Islands 

678 - Vanuatu 

679 - Fiji Islands 

680 - Palau 

681 - Wallis and 
Futuna Islands 

682 - Cook Islands 

683 - Niue 

684 - American 
Samoa 

685 - Western Samoa 



686 - Kiribati 

687 - New Caledonia 

688 - Tuvalu 

689 - French 
Polynesia 

690 - Tokelau 

691 - Micronesia 

692 - Marshall 
Islands 

Asia (AS) 

7 - Russia/CIS 

81 - Japan 

82 - South Korea 
84 - Vietnam 
850 - North Korea 

852 - Hong Kong 

853 - Macau 

855 - Cambodia 

856 - Laos 

86 - China (PRC) 
880 - Bangladesh 
886 - Taiwan 

90 - Turkey 

91 - India 

92 - Pakistan 

93 - Afghanistan 

94 - Sri Lanka 

95 - Burma 
(Myanmar) 

960 - Maldives 

961 - Lebanon 

962 - Jordan 

963 - Syria 

964 - Iraq 

965 - Kuwait 

966 - Saudi Arabia 

967 - Yemen 

968 - Oman 

971 - United Arab 
Emirates 

972 - Israel 

973 - Bahrain 

974 - Qatar 

975 - Bhutan 

976 - Mongolia 

977 - Nepal 
98 - Iran 

993 - Turkmen! s tan 

994 - Azerbaijan 

995 - Georgia 
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5 Referring now to Figure 7, this figure illustrates an overview of the 

computer-implemented process for generating a rate plan and transferring it to a 
clearinghouse system 50. Step 710 is the first step in the computer-implemented 
process of the internet telephony rate provisioning method and system 35, where rates 
for a single network device are identified according to calling zones or exceptions to 

10 the calling zones or both. Inliri exemplary embodiment, the network devices can be 
gateways 108 or 114 that are part of the clearinghouse system 50. However, the 
present invention is not limited to these types of network devices and can include 
other similar network devices. Other network devices include, but are not limited to, 
routers, gatekeepers, and other similar network devices. 

15 Next, in step 715, network device information and rate information are entered 

into pre-assigned cells of a rate table such as the rate table 600 as illustrated in 
Figure 6. Network device information can include a customer identification number, 

a device name (the Internet protocol address~of a device), a service -type (voice or 

fax), a type of plan (originating or terminating) the currency identification number, 

20- and^a„ rate__plan name. Basically, the rate information can correspond to 
cells 610A-610F, as illustrated in Figure 6. A single rate table 600 is created for each 
device, each service type of the device, and each role of device. That is for a single 
device, several rate tables 600 may be needed. Exemplary scenarios that require 
separate rate tables 600 include, but are not limited to the following: a gateway that 

25 supports fax service in an originating role; a gateway that supports fax service in a 
terminating role; a gateway that supports voice service in an originating role; and a 
gateway that supports voice service in a terminating role. Thus, for each identified 
scenario, a separate rate table can be employed. 

With the inventive system, the user could be provided with a template for an 

30 ordinary spreadsheet program such as Microsoft Excel for the purposes of entering the 
rate plan information. In an exemplary embodiment, the user would then save the 
Excel file as a CSV file prior to submitting it to the clearinghouse system 50. Users, 
therefore, have the flexibility to bypass the spreadsheet program and create a CSV file 
directly. Rate Table 600 can be designed for any increments of time. In one 

35 exemplary embodiment, each rate table can denote a weekly schedule that includes a 
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single 24X7 time period. Add tionally, rates indicated in the rate table 600 can be in 
increments of rates per minute. However, other time increments are not beyond the 
scope of the present invention. Bach rate table is associated with a single currency 
tool7~Iii one exemplary environment, it is assumed there is only one clearinghouse 
account established for each user, and each clearinghouse account is associated with 
only one currency. 

In one exemplar^embbdiment, an account can be established for each 
currency so that a user can select, within a single rate table, the currency associated 
with each rate listed in the table. 

Each rate table 600 and its corresponding CSV file will be validated to 
ensure that the currency designated in the rate plan table 600 is equal to the currency 
associated with the user's clearinghouse account maintained in database 120 of the 
clearinghouse system 50. 

_ Nex t, in step 720, the-rate table 600 is stored in a file format that preserves the 
relative locations of the pre-assigned cells of the rate table 600. In one exemplary 
embodiment, the CSV file format is used to preserve the relative locations of the 
pre-assigned cells. However, as noted above, the present invention is not limited to 
the CSV file format. Other formats can be utilized as long as the relative locations of 
the pre-assigned cells can be reconstructed by the clearinghouse system 50 after it is 
transferred to the clearinghouse. 

After step 720, in routine 725, the file containing the rate table is transferred to 
the centralized or clearinghouse system 50. Further details of routine 725 will be 
discussed below with respect to Figures 8 and 10. In one exemplary embodiment, the 
rate table preserved in each file will typically include a complete set of rate plan data 
that is equivalent to an instance or version of a rate plan. That is, the rate table will 
typically include sufficient information to rate all traffic to all configured number 
prefixes from the date on which the file is sent to the clearinghouse system 50. For 
each number string of the rate plan data, there typically must be at least one row with 
a "begin date" equal to or less than the current processing date. A file may include 
rates that become effective in the past and continue to be in effect. Therefore, a user 
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is not requested to restate "begin dates" each time a file is sent, and the file may 
represent a cumulative view of all previous versions of the file. 

After routine 725, in routine 730, the rate plan data contained within a 
transferred file is received and validated. Further details of routine 730 will be 
discussed below with respect to Figures 9 and 11. All times relating to rate plan data 
as well as processing of the plan data by the~clearinghouse~system 50 is typically 
UTC-based. For example, upload or transferred date/time means upload or 
transferred date/time UTC. Also, the system time of the clearinghouse system is 
converted to system time UTC whenever the file is stored or used in a calculation. 
Rate plan effective dates and assignment effective dates displayed in the user interface 
are also UTC-based. 

Also in step 730, once the set of new rate plan data for the device is stored in 
the Billing Engine database, all previous rate plan data sets (previous assignment 
eff«Jiye::jiates)rfor--^^ be 
-flagged-as "superseded'V and these can-be maintained in-the Billing-Engine database 
fo r a set period of time. Only the current version of the rate plan data is used to build 
views that are transmitted periodically to the database of the Service Points 112 where 
real-time routing decisions are made . When the Routing Engine 110 at the Service 
Point 112 makes a routing decision, it records the rate plan identification number in a 
call detail record. The call detail records are periodically transmitted from the Service 
Point 110 to the Billing Engine database. The rate plan identification number written 
to the call detail record is subsequently used by the Billing Engine to identify the rate 
to be used to rate the call for billing purposes.Next, in decision step 735, it is 
determined whether a successful validation has occurred. If the inquiry to decision 
step 735 is negative, then the "no" match is followed back to step 710. If the inquiry 
to decision step 735 is positive, then the "yes" match is followed to step 740. In 
step 740, the rate information from the rate table is stored in the Billing Engine 
database from which it is transmitted to the Service Point(s) 112 after a predefined 
period of time. Typically, the clearinghouse system 50 will disseminate rate plan data 
to service point 125 within 48 hours of receipt of the rate plan file. The new rate plan 
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data set will have an assignment effective date equal to the date/time when the date is 

written to the Billing Engine database 122 plus 24 hours. 

Thereafter, it will be possible for users to view rate plan data (retrieved from 

the Billing Engine database) through a user interface supported by web site 122. 

Users will be able to view the most current set of rate plan data only for their devices. 

The user interface selects from the Billing Engine database and displays rate plan data 

with the most curient upload date/time. 

After step 740, in decision step 745, it is determined whether a request to view 

rate information has been received. If the inquiry to decision step 745 is negative, 

then the "no" branch is followed. If the inquiry to decision step 745 is positive, then 

the "yes" branch is followed to step 750, in which the rate plan information is 
displayed on website 122 through a user interface. 

Referring now to Figure 8, this figure illustrates a computer-implemented 
process-for-the-transfer-^ in 
- routine 725A, in which-an e-mail message as set forth in Figure 4 is created. Next, in 
step 81 5A, portions of the device information is identified in a predefined format in 
the subject line 430 of the e-mail message 410. In step820A, the file created in 
step 720 is attached to the e-mail message 410. Next, in step 825A, the e-mail 
message 410 is sent to the centralized or clearinghouse system 50. In step 830A, the 
process returns to routine 730 of Figure 7. The present invention is not limited to the 
aforementioned transfer methods. Other transfer methods include, but are not limited 
to, fax, forwarding files on disk, and other like methods. 

Referring now to Figure 9, this figure illustrates a computer-implemented 
process for the receive and validate data routine 730 of Figure 7. Step 91 OA is the 
first step in routine 730A, in which receipt of the file transferred in step 725 to the 
centralized or clearinghouse system 50 is logged. In step 91 5 A, the CSV file is stored 
in a rate plan database 120. Next, in step 920A, the status of the file is logged. In this 
step, once it becomes possible for a user to upload the rate plan file via an upload link 
on the user interface, a real-time review is performed and the user can be advised 
immediately if the rate plan file is accepted for further processing. In step 925 A, data 
contained within the CSV file is validated. The validation process can include, but is 



WO 01/47235 



PCT/US00/35069 



5 not limited to, comparing da a within the reconstructed rate plan tahle with a cell 

assignment template, in comparing device information against device information 

contained within the database 120. Other exemplary validation functions include, but 

are not limited to the following: (Examples of preliminary validation, before storing 

the file in the website exemplary embodiment of Figures 10 and 11, include items 1 

~~i0 £firoup~6~T^low: "Secondary "vatdatio^ 

"following uploading include items 7 and 8 below. For the E-mail exemplary 

embodiment of Figures 9 and 10, both preliminary and secondary validation will take 
* 

place at the time the file is processed following receipt of the file via e-mail.) 
1 . Validate field values according to Tables III and Table IV. 
15 2. Validate that there are no duplicate rows for the combination of Zone, CC, 

City/NPA-NXX and Begin Date. 

3. Validate that there is at least one row with "Zone" = "OT" 

4 ^Validaterthat foneachrcombinatiomof-Zone , jG C, a nd-Gity/NPA-NXX there 

is at least one row with a -'Begin Date" equal to or less than the-current processing 
20 Jate (sysdate).„ 

5. Validates that required fields are populated. 

If "Allow" = "Y" and "Role" = "O", there must be a valid value in each field 
except "Maximum Delay (ms)". 

If "Allow" = "Y" and "Role" = "T", there must be a valid value in each field 
25 except "Maximum Delay (ms)" and "Routing Priority". 

If "Allow" = "N" and "Role" = "O" or "T'\ there must be a valid value in each 
field except "Rate", "Unit of Measure", "Increment", "Maximum Delay (ms)" and 
"Routing Priority". 

6. Validate that the first row of rates is preceded by a row with "BEGIN" in 
30 the "Zone" field, and the last row of rates is followed by a row with "END" in the 

"Zone" field. 

7. Validate the combination of "Customer ID" and "Device Name". 

8. Validate combination of "Customer ID" and "Device Name" with "Role". 

9. If there is a value in Column A of the rate plan table, there cannot be values 
35 in Columns B and C and vice versa. 
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10. Validate "Currenc)" with customer's clearing account currency or user's 
currency in a user table 

The present invention is not limited to the aforementioned validation 
functions or techniques. The present invention could include any number of 
validation functions or techniques or both. In step 930A, the result of the validation 
^te^925A^s-rogged:~Innoto can 
display the status of the file from receipt through secondary validation and storage of 
rate plan data in the Billing Engine database, at which point this data is viewable by 
the user via the user interface. In step 935A, the process returns to step 35 of 
Figure 7. 

Referring now to Figure 10, this figure illustrates another 
computer-implemented process for the transfer of file routine 725 of Figure 7. 
Step 1010 is the first step of routine 725B, in which the user interface of the 
-eentralized-or-e^ on-webstteJ-22._ In step 1015, an 
- upload link such as-link 540, -as-illustrated- in - Figure-5,-is activated. Next, in 
step 1020, the location of the CSV file created in step 720 is identified. In step 1025, 
the uploading process for the CSV file is initiated. In step 1030, the process returns to 
routine 730 of Figure 7. 

Referring now to Figure 11, this figure also illustrates another computer- 
implemented process for the receive and validate routine 730 of Figure 7. Step 1110 
is the first step of routine 730B in which a first validation process is initiated while the 
file data is being received during the transfer process. This first validation process 
can be referred to as a preliminary validation before the rate plan data is written or 
stored in the database 120. Next, in step 1115, the CSV file transferred in step 725 is 
stored in the rate plan database 120. In step 1120, a second validation process is 
initiated. In decision step 1125, it is determined whether a successful validation 
process has occurred. If the inquiry to decision step 1125 is negative, then the "No" 
branch is followed to step 1140. If the inquiry to decision step 1125 is positive, then 
the "Yes v branch is followed to step 1130 in which the file data is forwarded to tables 
in the Billing Engine database from which the web site 122 retrieves rate plan data as 
illustrated in Figure 2. 
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5 In step 1135, a message is sent to the user acknowledging the successful 

validation of the reconstructed rate plan table. After step 1135, the process proceeds 
to step 1145 in which the tracking information pertaining to the upload is logged. 
That is, parameters such as the upload time is recorded in UTC based time. In step 
1 140, a message is sent to the user and to the centralized for clearinghouse system 50 

l"0™^indicafing ffiaf unsud£¥slM "va^ 

error details that identify any specific problems with the "CSV file that was transferred. 
In step 1150, the process returns to decision step 735 of Figure 7. 

It should be understood that the foregoing relates only to illustrative 
embodiments of the present invention, and numerous changes may be made therein 

15 without departing from the spirit and scope of the invention as defined by the 
following claims. 
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5 What is claimed is: 

1 . A method for creating and implementing a rate plan for a network device 
within an Internet telephony clearinghouse system, comprising the steps of: 
identifying calling rates for a single network device; 
10 placing network device information and the calling rates into 

preassigned cells of a rate table; 

storing the table in a file format that preserves relative locations of the 
preassigned cells in the rate table; and 

transferring the file to a the Internet telephony clearinghouse system. 

15 

2. The method of claim 1, wherein the step of identifying calling rates further 
comprises identifying calling rates according to at least one of predefined calling 
fc zones and country-city code combinations 

20 3. The method of claim 2, wherein the step of identifying calling rates further 

comprises identifying calling rates according exceptions to the calling zones. 

4. The method of claim 1, wherein network device information comprises at 
least one of a customer identification number, an Internet Protocol address for the 

25 network device, a type of service supported by the network device, a type of traffic 
supported by the network device, and a rate plan name. 

5. The method of claim 1, wherein the file format comprises a comma 
separated values (CSV) format. 

30 

6. The method of claim 1, wherein the step of transferring the file, further 
comprises transferring the file via an E-mail message. 
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7. The method of clium 1, wherein the step of transferring the file, further 
comprises transferring the fi)e via a file transfer protocol and real-time validation 
supported by a website. 

8. A method for creating and implementing a rate plan for a network device 
~within"an~InteTnet telephonjrciearinghouse system, comprisingthestepsof: 

receiving a file "in '^predefined formartfiatcdntains relative locations 
of preassigned cells in a rate table; 

validating the rate plan data; storing the rate plan data in a database; 

and 

periodically transmitting selected rate plan data to a service point 
network devices where routing decisions are made. 

9. Th e method of claim 8, wherein the file format comprises a comma 
separated values (CSV) format. 

10. The method of claim 8, wherein the step of receiving the file, further 
comprises receiving the file via an E-mail message. 

1 1. The method of claim 8, wherein the step of transferring the file, further 
comprises receiving the file via a file transfer protocol supported by a website. 

12. The method of claim 8, wherein the step of validating the rate plan data 
further comprises comparing the rate plan data to a rate table template listing 
acceptable ranges of values for particular cells. 
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